Oracle 19c ADG Swithover 切换手册

作者 | JiekeXu

来源 | JiekeXu DBA之路（ID: JiekeXu_IT）

大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来看看 Oracle 19c ADG Swithover 切换流程，欢迎点击上方蓝字关注我，标星或置顶，更多干货第一时间到达！

本文档主要是根据前面文档中搭建的 Oracle 19c MAA 架构的备库进行 Swithover 切换，然后将备库变为主库，主库变为备库，达到一个迁移的目的。

源地址IP为 192.168.0.86/87，目标端IP地址段为：192.168.21.81-87。规则如下：其中81/82/83为SCAN，86/84为一节点的PUB/VIP，87/85为二节点的PUB/VIP。

其中IP地址列表如下：

源端IP	192.168.0.86/87	目标端IP	192.168.21.86/87
源端版本	Linux7 RAC 19.4.0	目标端版本	Linux7 RAC 19.4.0
源端字符集	AL32UTF8	目标端字符集	AL32UTF8
源端db	edw	目标端db	edwstb

文章标题《Oracle 19c ADG Swithover 切换手册》那必定可以当手册使用，文档也已经整理好了，在本公众号后台回复关键字【ADG切换手册】获取本文文档版本。

1、切换前准备工作

Ø 检查集群状态，监听状态

crsctl status  res -t
lsnrctl status

Ø 检查主备库打开状态，模式

检查数据库实例状态，正常状态为open
select instance_name,status from gv$instance;
检查数据库打开模式
OPEN_MODE正常状态为READ WRITE
LOG_MODE正常状态为ARCHIVELOG 
DATABASE_ROLE正常状态为PRIMARY
select INST_ID,NAME,open_mode,LOG_MODE,DATABASE_ROLE,PROTECTION_MODE,DB_UNIQUE_NAME from  gv$database;

Ø 主备库的 DG 参数检查确认

show parameter db_file_name_convert
show parameter log_file_name_convert
show parameter standby_file_management
show parameter fal_client
show parameter fal_server
show parameter log_archive_config
show parameter log_archive_dest_2
show parameter log_archive_dest_2_state

Ø 检查主库

col DEST_NAME for a30
select DEST_ID,DEST_NAME,STATUS,RECOVERY_MODE from V$ARCHIVE_DEST_STATUS where DEST_NAME='LOG_ARCHIVE_DEST_2';
status正常状态为VALID ，如果备库停止日志传输，设置defer则status为BAD PARAM RECOVERY_MODE正常状态为 MANAGED REAL TIME APPLY
如果备库恢复模式不是“REAL TIME APPLY”，备库重启日志恢复进程，起用“REAL TIME APPLY”
[备库][oracle用户][节点1]
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Ø 检查主库、备库确定有足够的归档进程

log_archive_max_processes值需大于等于4，但也不会太大。
show parameter  LOG_ARCHIVE_MAX_PROCESSES

Ø 检查standby redo是否创建了

select * from v$logfile;

Ø 备库检查redo logs是否需要清理

[备库][oracle用户][节点1][SQL]
备库查询redo logs是否需要清理，有数据则说明需要清理
SQL>SELECT DISTINCT L.GROUP# FROM V$LOG L, V$LOGFILE LF
     WHERE L.GROUP# = LF.GROUP#
     AND L.STATUS NOT IN ('UNUSED','CLEARING','CLEARING_CURRENT');

如果存在需要清理的redo,可通过以下两种方式处理:
1）备库设置LOG_FILE_NAME_CONVERT参数，主备切换时会自动清理redo logs,该参数为静态参数，如搭建时未设置，设置需重启数据库生效。如该参数已设置，官方仍建议切换前清理redo logs
show  parameter LOG_FILE_NAME_CONVERT;
设置方法：
alter system set log_file_name_convert='+ARCH','+ARCH' scope=spfile;
shutdown immediate;
startup;
2）需要停止日志应用，通过group#清理redo logs
取消日志应用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
清理redo logs
SQL> ALTER DATABASE CLEAR LOGFILE GROUP <需要清理的日志组号>;
重新应用日志
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Ø 检查主库standby日志情况

检查主库是否创建了standby的redo log日志

注意：standby的redo log日志要比源库的redo log日志多一组，大小和redo log大小一致，例如源库数据库的 redo log 为2组4个，那么standby 的redo log应该为3组6个

1）查看redo log情况

select group#,thread#,sequence#,members,archived,status,bytes/1024/1024  M from v$log order by 1;

2）查看standby日志情况

col MEMBER for a50
select GROUP#,THREAD#,BYTES/1024/1024  M,STATUS  from v$STANDBY_log;
如果主库没有standby日志组，可使用如下语句添加
添加standby日志组：（比主库多添加一组）
alter database add standby logfile thread 1 size 512m;
alter database add standby logfile thread 1 size 512m;
alter database add standby logfile thread 1 size 512m;
alter database add standby logfile thread 2 size 512m;
alter database add standby logfile thread 2 size 512m;
alter database add standby logfile thread 2 size 512m;

Ø 备库查询应用到的日志REDO SEQUENCE

主库查询当前的REDO SEQUENCE

SELECT THREAD#, SEQUENCE# FROM V$THREAD;

备库查询应用到的日志REDO SEQUENCE ，正常查询结果和上面主库的REDO SEQUENCE 数值只差1～2个

SELECT THREAD#, MAX(SEQUENCE#) FROM V$ARCHIVED_LOG
     WHERE APPLIED = 'YES'
     AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE#
     FROM V$DATABASE_INCARNATION WHERE STATUS = 'CURRENT')
     GROUP BY THREAD#;

Ø 备库检查数据库是否有gap

检查数据库是否有gap，正常没有
select thread#,low_sequence#,high_sequence# from v$archive_gap;

Ø 检查下当前应用进程是否有延时

column name format a13;
column value format a20;
column unit format a30;
column TIME_COMPUTED format a30;
select name,value,unit,time_computed from v$dataguard_stats where name in ('transport lag','apply lag');

Ø 关闭应用并确认当前连接会话

select username,sid,status,event,program,machine,sql_id from v$session where username !='SYS';
  
select username,sid,status,event,program,machine,sql_id,logon_time from gv$session where username !='SYS' order by logon_time desc;

Ø 主库、备库确定数据文件、临时文件状态

确定主备数据库临时文件一致，且所有的数据文件都是online的

col FILENAME for a50
SELECT TMP.NAME FILENAME, BYTES/1024/1024 M, TS.NAME TABLESPACE FROM V$TEMPFILE TMP, V$TABLESPACE TS WHERE TMP.TS#=TS.TS#;
 
SELECT NAME FROM V$DATAFILE WHERE STATUS='OFFLINE';
如果存储offline的数据文件，且是切换为主库所需要的数据文件，需要online
SQL> ALTER DATABASE DATAFILE 'datafile-name' ONLINE;

Ø 主库验证当前是否可转换为备库

检查主库 switchover_status状态，正常结果为TO STANDBY或SESSION ACTIVE

select switchover_status from v$database;

注意事项：

如果switchover_status为TO_STANDBY说明可以直接转换

alter database commit to switchover to physical standby;

如果switchover_status为SESSIONS ACTIVE ，但是查询V$SESSION会话，都是系统会话，可以通过如下命令在主库进行SWITCHOVER切换。

alter database commit to switchover to physical standby with session shutdown;
 
SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
----------------------------------
TO STANDBY 或者SESSIONS ACTIVE
 
--备库状态
SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;
 
SWITCHOVER_STATUS
--------------------
NOT ALLOWED

Ø 再次确认下主库上面的crontab job是否转移到备库上了

crontab -l

2、正式切换 switchover

1. 修改主库ORA30A参数（当主备库的目录结构不一致时需要修改此参数）

#以下参数需要重启方能生效
alter system set db_file_name_convert='+DATA','+DATA' scope=spfile;
alter system set log_file_name_convert='+FRA','+FRA' scope=spfile;

2. 修改备库ORA30A_JX参数（当主备库的目录结构不一致时需要修改此参数）

#以下参数需要重启方能生效
alter system set db_file_name_convert='+DG_DATA/ora30astd_jx' ,'+DG_DATA/ora30a_jx' scope=spfile;
alter system set log_file_name_convert='+DG_REDO/ora30astd_jx','+DG_REDO/ora30a_jx' scope=spfile;

本次 MAA 切换不需要修改此参数。

3. edw主库关闭实例2

srvctl stop instance -d edw -i edw2 -o immediate

4. edwstb备库关闭实例2

srvctl stop instance -d edwstb  -i edwstb2 -o immediate

5. edw主库切换到standby

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

6. 验证备库的切换状态

SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO PRIMARY  --如果备库为 SESSIONS ACTIVE 但查询没有会话则可以重启一下

7. 切换备库为主库

SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
SQL>alter database open;

8. 打开新备库的日志同步进程

SQL> startup mount
 
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

9. 验证切换后的结果

主库进行日志切换，查看备库的日志，看是否开始接收并应用。

经过检查多次切换日志，新备库均没有接受到日志，这个可能的原因比较多，按照之前说的检查备库 alert 日志，没有报错，只有一句提示：

2021-06-09T18:50:01.005734+08:00

TT02 (PID:26883): LOG_FILE_NAME_CONVERT is not defined, stop clearing ORLs

那么既然有这个提示就修改一下这个参数吧。只在备库修改，然后重启备库，应用日志后还是没有同步。

ALTER SYSTEM SET db_file_name_convert='+DATA','+DATA' SCOPE=SPFILE;
alter system set log_file_name_convert='+DATA','+DATA' scope=spfile;

不过终于在主库的 alert 日志中发现了错误 ORA-16047

ORA-16047: DGID mismatch between destination setting and target database

2021-06-09T19:27:17.609158+08:00

查看错误居然报备库 DB_UNIQUE_NAME 不匹配，检查备库参数后也没问题。

[oracle]$ oerr ora 16047
16047, 00000, "DGID mismatch between destination setting and target database"
// *Cause:  The DB_UNIQUE_NAME specified for the destination did not match
//          the DB_UNIQUE_NAME at the target database.
// *Action: Ensure that the DB_UNIQUE_NAME specified in the LOG_ARCHIVE_DEST_n
//          parameter matches the DB_UNIQUE_NAME parameter defined at the
//          destination.

然后通过以下视图查看时，在新主库上发现了错误。参数 LOG_ARCHIVE_DEST_2 配置错误，参数中 SERVICE 和 DB_UNIQUE_NAME 果然不匹配，重新修改后备库立马恢复正常，同步正常。

select dest_name,status,error from v$archive_dest;
 
19:37:22 SQL> show parameter LOG_ARCHIVE_DEST_2
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2                   string      SERVICE=EDWSTB LGWR ASYNC VALI
                                                 D_FOR=(ONLINE_LOGFILES,PRIMARY
                                                 _ROLE) DB_UNIQUE_NAME=edw
 
19:37:32 SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=EDW LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=edw';
 
System altered.
 
Elapsed: 00:00:00.03
19:38:20 SQL> select dest_name,status,error from v$archive_dest;
 
DEST_NAME                      STATUS    ERROR
------------------------------ --------- -----------------------------------------------------------------
LOG_ARCHIVE_DEST_1             VALID
LOG_ARCHIVE_DEST_2             VALID
LOG_ARCHIVE_DEST_3             INACTIVE

10. 备库只读打开(可选)

可根据实际情况，选择是否打开备库。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> alter database open;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

11. 打开RAC的另一个节点

主库和备库的另一个节点都可以打开。

startup

3、检查修改DBLINK

由于迁移主机发生变化了，因此需要检查确认是否有其他数据库配置了到本数据库的DBLINK连接。检查下是否存在其他库到本库的DBLINK，若有，则在那些库上面，修改dblink涉及到的本数据库服务器IP地址。

select * from dba_db_links;

4、修改应用连接 IP 地址

由于数据库服务器IP地址发生了变化，因此需要将应用连接到数据库的IP地址也进行修改。

5、启应用

以上步骤全部完成之后，启应用，检查日志并确认下应用连接是否正常，业务测试。

---

本次分享到此结束啦~

❤️ 欢迎关注我的公众号，来一起玩耍吧！！！

——————————————————————--—--————

公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
腾讯云：https://cloud.tencent.com/developer/user/5645107

————————————————————————----———